The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

[00:04:11] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:11] tidy error: /checkout/src/librustc_traits/dropck_outlives.rs:37: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc_traits/evaluate_obligation.rs:29: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/infer/mod.rs:515: line longer than 100 chars
[00:04:12] some tidy checks failed
[00:04:12] 
[00:04:12] 
[00:04:12] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:12] 
[00:04:12] 
[00:04:12] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:12] Build completed unsuccessfully in 0:00:46
[00:04:12] Build completed unsuccessfully in 0:00:46
[00:04:12] make: *** [tidy] Error 1
[00:04:12] Makefile:79: recipe for target 'tidy' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:036ba66c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:05b627e0:start=1538764766927338529,finish=1538764766932375446,duration=5036917
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1304fcf0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0d1bd67c
travis_time:start:0d1bd67c
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:1d28ea21
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@arielb1

I'm not sure I prefer "superuniverse" to "subuniverse". Universes naturally form a tree, and the "subelement" relationship goes from a universe to its sub/superuniverse.

It seems like the use of "subuniverse" conflicts with methods like is_subset_of -- i.e., U0 is a "subset" of U1. Perhaps we can find some other terminology. I've found it pretty important when writing this code to have something that gives the right intuition.

Maybe "extension" and "extended" is a better terminology?

e.g.,

• create_subuniverse => create_extended_universe
• is_subset_of => is_extended_by

and so forth?

(For that matter, create_superuniverse should perhaps just be called create_universe or create_fresh_universe, with the "extension" aspect of it left to doc comments -- i.e., "creates a fresh universe that extends all previous universes")

Rebased and tidied. Went and tried the renaming I proposed. I wound up at a slightly different place, as you can see in the comment from the final commit:

remove the sub/super terminology for universes

Instead, we talk about:

• creating the "next" universe
• universes "extending" one another
• and u1.can_name(u2), meaning that u1 contains all names from u2

Now I am thinking create_child_universe might be better than "next" universe, to help build on the tree intuition. Unclear how much that matters though.

@bors r+

📌 Commit bae8a5ac3e5cbe85bade7f1313712fb8bc114a6d has been approved by scalexm

seems to be broken?

error: internal compiler error: librustc\infer\canonical\canonicalizer.rs:175: unexpected region in query response: `ReEarlyBound(0, 'i)`

in the rollup

https://ci.appveyor.com/project/rust-lang/rust/builds/19415197/job/kex1uawo1pxeg0ml

☔ The latest upstream changes (presumably #54969) made this pull request unmergeable. Please resolve the merge conflicts.

@bors r=scalexm

📌 Commit 5be9513ce4a6e593f5c50eab972de94ee8f60dd1 has been approved by scalexm

⌛ Testing commit 5be9513ce4a6e593f5c50eab972de94ee8f60dd1 with merge 0e86b363814cfd66862f6df73bec3e5f63115b7c...

💔 Test failed - status-appveyor

Whoops, I thought I had patched that problem.

@bors r=scalexm

📌 Commit 05f67ca has been approved by scalexm

⌛ Testing commit 05f67ca with merge 5a52983...

☀️ Test successful - status-appveyor, status-travis
Approved by: scalexm
Pushing 5a52983 to master...